FIG. 1 gives a schematic system view of a Portal server implementing a prior art Web Portal. A prior art Portal, for example as represented by IBM WebSphere Portal or by Jetspeed2 Enterprise Portal (www.Portals.apache.org/jetspeed-2/Portal-design.html), is built by a complex functionality implemented on a network server—for example a Web server 100, the most important elements of which are logic components for user authentication 105, state handling 110, aggregation 170 of fragments, a plurality of Portlets 120 (further described below) provided in respective pages 125 with a respective plurality of APIs 130 to a respective Portlet container software 135 for setting them into the common Web page context, and some Portal storage resources 140. The logic components are operatively connected such that data can be exchanged between single components as required. This is roughly depicted in FIG. 1.
In more detail, a Portal engine of the Web server in FIG. 1 implements an aggregation of Portlets 120 based on the underlying Portal model 150 and Portal information such as security settings, user roles, customization settings, and device capabilities. Within the rendered page, the Portal automatically generates the appropriate set of navigation elements based on the Portal model. The Portal engine invokes Portlets during the aggregation as required and when required and uses caching to reduce the number of requests made to Portlets. The prior art IBM WebSphere Portal employs open standards such as the Java Portlet API (application programming interface). It also supports the use of a remote Portlet via the WSRP (Web Services for Remote Portlets) standard.
The Portlet container 135 is a single control component competent for all Portlets 120, which may control the execution of code residing in each of these Portlets. It provides the runtime environment for the Portlets and facilities for event handling, inter-Portlet messaging, and access to Portlet instance and configuration data, among others. The Portal resources 140 are in particular the Portlets 120 themselves and the pages 125, on which they are aggregated in the form of an aggregation of fragments. A Portal database 128 stores the portlet description, featuring some attributes like portlet name, portlet description, portlet title, portlet short title, and keywords, as well as the portlet interaction interface description, which is often stored in the form of WSDL (Web Services Description Language) documents. The Portal database also stores the Portal content structure, i.e. the hierarchical structure of portal pages, which may again contain nested pages, and portlets. This data is stored in the database 128 in an adequate representation based on prior art techniques like relational tables.
The before-mentioned aggregation logic 170 includes all steps that are required to assemble a page. Typically, these steps are to load a content structure from storage, to traverse it and to call the instances referenced in the structure in order to obtain their output, which is assembled to a single page.
The content structure may be defined through, for example, Portlet Customization by the administrators or users and saved in the database, or by other ways, e.g. scripting, XML import, etc.
Web portals are often used to perform a semantically unitary business step, such as, for example, booking travel for a particular person. Typically, such a business step includes a plurality of distinct business items, which are processed separately in respective distinct portlets or generally, applets, respectively. For example, in the case of travel booking, one portlet may be used to book the flight, another portlet to book the hotel, and a third portal to book a rental car during the holidays. Possibly another portlet may be used for to employ a house keeping person for the holiday. Typically, these multiple applets or portlets are programmed and sold by different software producers. So, in general, they might be implemented in a single Web portal, but they have no common data interface for exchanging data.
When a user works within in a portal application having such multiple portlets, he will usually follow a certain flow of action, for example first booking the flight, then booking the hotel, then booking the rental car, etc. Business practice, however, shows that a person booking travel is often distracted from their work, for example by telephone calls requiring another piece of work more urgent than the one the user had already begun working on. As a result, he is constrained to leave his usual flow of work. In the travel booking example the user might be constrained to book a second travel booking before he has completed a first travel booking.
A first problem and disadvantage of existing systems relates to storing information a first user has already input into a portlet, when the same portlet is then used by another customer. Disadvantageously, existing Web applications, including existing Web portal software solutions, do not offer a good mechanism for intermediately storing such information. Unfortunately, such information often has a high business value, since it is often obtained by inputs from a customer. If such information has to be input a second time, this would represent an undue burden for a customer.
A second problem with existing systems is that even if a user succeeds in storing input data such as customer name, customer travel dates, customer hotel, etc. within a clipboard-like temporary storage, such as the Microsoft Windows® Clipboard, thus storing the data externally from the Web application, handling of this data storage is difficult because the data handling is managed on a different system level than that at which the user is working with. For example, the Windows Clipboard mechanism, which allows copying and pasting of such data, is implemented on the operating system level, whereas the user is working at a Web portal level. The problem is that the temporarily stored data must be selectively marked and separately pasted into respective input fields of the target portlet. Accordingly, a skilled reader easily appreciates that it is quite difficult to manage such copy-pasted data, other than by using an editor program, such as, for example, the Windows WordPad and the like.
More particularly, if a user is confronted with doing three distinct threads of travel bookings, for example for three different customers, then the handling of such an editor is quite complicated. Another disadvantage is that even if he manages to copy and paste correctly, then the user is constrained to copy-paste many data items separately, for example, first copying the first name of a person and pasting it into a respective field of a portlet, and then copying the last name and pasting it in a second field of the same portlet. However, as the user uses, for example, three portlets for booking a flight, hotel and the rental car, such manual copy-paste mechanisms are troublesome and error-laden. If the user is not equipped with enough screen area to display the editor window close to the portlet window, he even would be constrained to open and close the respective windows before pasting a data item into the correct field. Accordingly, data handling using such existing systems becomes quite complicated, and is not tolerable for serious and efficient business use.
It is accordingly an objective of the present invention to provide an improved method and system offering increased ease of use, and offering an improved data exchange mechanism.